home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Chapter 11
- MORE VIRTUAL FUNCTIONS
-
- This chapter will actually be a continuation of the topics covered
- in the last chapter but this will be a fuller explanation of what
- virtual functions are and how they can be used in a program. We
- will present a simple database program with a virtual function to
- show how it can be used, then we will go on to illustrate a more
- complex use of the virtual function in a manner that finally
- illustrates its utility and reason for existence.
-
-
- HOW TO START AN OOP PROJECT
- _________________________________________________________________
-
- The observant student will notice that we begin our use of object
- oriented programming by identifying an object, or in this case a
- class of objects and even some subordinate objects, which we
- completely define. When we get to the main program we then have
- a simple job with the remaining needs and they are completed using
- standard procedural programming techniques which we are familiar
- with. This is the way to begin any object oriented programming
- project, by first identifying a few objects that can be separated
- conveniently from the rest of the code, programming them, then
- writing the main program. It should be added that, for your first
- project using objects, do not try to make everything an object.
- Select a few objects and after gaining experience with object
- oriented programming techniques, use more objects on future
- projects. Most programmers use too many objects for their first
- project and write very obtuse, unreadable code.
-
-
- THE PERSON HEADER FILE
- _________________________________________________________________
-
- Examine the file named PERSON.H for the ================
- definition file for the person class. This PERSON.H
- class definition should cause you no problem to ================
- understand since there is nothing new here. The
- only thing that should be mentioned about this
- class is that the protected mode is used for the variables so that
- they are readily available in the derived classes which will
- inherit this class.
-
- THE PERSON IMPLEMENTATION
- _________________________________________________________________
-
- The implementation for the person class is given here and it is a
- little strange in the way it is written and used. The intent of
- this program is that the virtual method named display() in this
-
- Page 11-1
-
- Chapter 11 - More Virtual Functions
-
-
- file will never be used, but it is required by ================
- the C++ compiler to be used for a default in PERSON.CPP
- case some of the subclasses do not have this ================
- function available. In the main program we will
- be careful to never call this function due to
- the nature of the program we are writing. Keep in mind that C++
- requires an implementation of all virtual functions even if they
- are never used. In this case the message is obviously intended to
- be output as an error message.
-
- Be sure to compile this program prior to going on to the next class
- definitions.
-
-
- THE SUPERVISOR HEADER
- _________________________________________________________________
-
- The file named SUPERVSR.H contains the class ================
- definitions for the three derived classes, SUPERVSR.H
- supervisor, programmer, and secretary. These ================
- were all placed in a single file for two
- reasons. The first reason is to simply
- illustrate to you that this can be done, and secondly, to allow
- some of the files to be combined on the disk and to require fewer
- compilations by you prior to executing the resulting program. This
- is actually a good way to combine these files since they are all
- derived classes of a common class. It is a matter of style or
- personal taste.
-
- You will notice that all three of these classes contain a method
- named display() and all have the same return value of void, and all
- have the same number of parameters as the parent class's method of
- the same name. All of this equality is required because they will
- all be called by the same call statement. You will also notice
- that the other method in each class has the same name, but
- different numbers and types of formal parameters which prevents
- this method from being used as a virtual method.
-
- The remainder of this file is simple and you should be able to read
- the code and understand it completely. Once again, this file
- cannot be compiled or executed.
-
-
-
- THE SUPERVISOR IMPLEMENTATION
- _________________________________________________________________
-
- The file named SUPERVSR.CPP contains the ================
- implementation for the three classes. If you SUPERVSR.CPP
- spend a little time studying the code, you will ================
- find that each of the methods named init_data()
- simply initializes all fields to those passed in
- as the actual arguments in a very simple manner.
-
- Page 11-2
-
- Chapter 11 - More Virtual Functions
-
-
- The method named display(), however, outputs the stored data in
- different ways for each class since the data is so different in
- each of the classes. Even though the interface to these three
- methods is identical, the actual code is significantly different.
- There is no reason code besides output could not have been used,
- but the output is so visible when the program is executed that it
- was chosen for this illustration.
-
- This file should be compiled at this time in preparation for the
- next example program which will use all four classes as defined in
- these four files.
-
-
- THE FIRST CALLING PROGRAM
- _________________________________________________________________
-
- The file named EMPLOYEE.CPP is the first program ================
- that uses the classes developed in this chapter, EMPLOYEE.CPP
- and you will find that it is a very simple ================
- program.
-
- We begin with an array of ten pointers, each pointing to the base
- class. As you recall from the last chapter, this is very important
- when using virtual functions, the pointer must point to the base
- class. The pointers that will be stored in this array will all
- point to objects of the derived classes however. When we use the
- resulting pointers to refer to the methods, the system will choose
- the method at run time, not at compile time as nearly all of our
- other programs have been doing.
-
- We allocate six objects in lines 16 through 39, initialize them to
- some values using the methods named init_data(), then assign the
- pointers to the members of the array of pointers to person.
- Finally, in lines 41 and 42, we call the methods named display()
- to display the stored data on the monitor. You will notice that
- even though we only use one method call in line 42, we actually
- send messages to each of the three methods named display() in the
- subclasses. This is true dynamic binding because if we were to
- change the values of some of the pointers in the array, we would
- then call different methods with the same pointers.
-
- Be sure to compile and execute this program before continuing on
- in this chapter. You will recall that the linking step requires
- you to combine several files in order to satisfy all system calls.
- After you have done that, we will use the same objects in another
- way to show how they can be reused.
-
- A PURE VIRTUAL FUNCTION
- _________________________________________________________________
-
- The pure virtual function is also available in the C++ toolbox of
- possible constructs. You can use a pure virtual function in the
-
- Page 11-3
-
- Chapter 11 - More Virtual Functions
-
- present example program by changing line 10 of PERSON.H to read as
- follows;
-
- virtual void display(void) = 0;
-
- You must then eliminate PERSON.CPP from the project or make
- sequence. An implementation for a pure virtual function cannot
- exist in the base class.
-
- Every derived class must include a function for each pure virtual
- function which is inherited into the derived class. This assures
- that there will be a function available for each call and none will
- ever need to be answered by the base class. You are not permitted
- to create an object of any class which contains one or more pure
- virtual functions because there is nothing to answer a message if
- one is sent to the pure virtual method. The compiler will enforce
- the two rules mentioned in this paragraph.
-
-
-
- THE LINKED LIST CLASS
- _________________________________________________________________
-
- Examination of the file named ELEMLIST.H will ================
- reveal the definition of two more classes which ELEMLIST.H
- will be used to build a linked list of employees ================
- to illustrate a more practical way to use the
- dynamic binding we have been studying in this
- chapter.
-
- The two classes were put in the same file because they work
- together so closely and neither is of much value without the other.
- You will notice that the elements of the linked list do not contain
- any data, only a pointer to the person class that we developed for
- the last program, so that the linked list will be composed of
- elements of the person class without modifying the class itself.
-
- There are two interesting constructs used here that must be pointed
- out before going on to the next program. The first is the partial
- declaration given in line 8 which allows us to refer to the class
- named employee_list before we actually define it. The complete
- declaration for the class is given in lines 22 through 29. The
- second construct of interest is the friend class listed in line 17
- where we give the entire class named employee_list free access to
- the variables which are a part of the employee_element class. This
- is necessary because the method named add_person() must access the
- pointers contained in employee_element. We could have defined an
- additional method as a part of employee_element and used this
- method to refer to the pointers but it was felt that these two
- classes work so well together that it is not a problem to open a
- window between the classes. We still have complete privacy from
- all other programs and classes declared as parts of this program.
-
-
- Page 11-4
-
- Chapter 11 - More Virtual Functions
-
-
- Note that the single method included in the employee_element class
- is implemented in inline code. Two of the methods of employee_list
- are still open so we need an implementation for this class.
-
-
- THE LINKED LIST IMPLEMENTATION
- _________________________________________________________________
-
- The file named ELEMLIST.CPP is the ================
- implementation for the linked list classes and ELEMLIST.CPP
- should be self explanatory if you understand how ================
- a singly linked list operates. All new elements
- are added to the end of the current list. This
- was done to keep it simple but a sorting mechanism could be added
- to sort the employees by name if desired.
-
- The method to display the list simply traverses the list and calls
- the method named display() in line 30 once for each element of the
- list.
-
- It is important for you to take notice that in this entire class,
- there is no mention made of the existence of the three derived
- classes, only the base class named person is mentioned. The linked
- list therefore has no hint that the three subclasses even exist,
- but in spite of that, we will see this class send messages to the
- three subclasses as they are passed through this logic. That is
- exactly what dynamic binding is, and we will have a little more to
- say about it after we examine the calling program.
-
-
-
- THE LINKED LIST IMPLEMENTATION
- _________________________________________________________________
-
- At this time you should examine the final ================
- example program in this chapter named EMPLOYE2.CPP
- EMPLOYE2.CPP for our best example of dynamic ================
- binding in this tutorial, yet the program is
- kept very simple.
-
- This program is very similar to the example program named
- EMPLOYEE.CPP with a few changes to better illustrate dynamic
- binding. In line 7 we declare an object of the class employee_list
- to begin our linked list. This is the only copy of the list we
- will need for this program. For each of the elements, we allocate
- the data, fill it, and send it to the linked list to be added to
- the list where we allocate another linked list element to point to
- the new data, and add it to the list. The code is very similar to
- the last program down through line 40.
-
- In line 43 we send a message to the display_list() method which
- outputs the entire list of personnel. You will notice that the
- linked list class defined in the files named ELEMLIST.H and
-
- Page 11-5
-
- Chapter 11 - More Virtual Functions
-
- ELEMLIST.CPP are never informed in any way that the subclasses even
- exist but they dutifully pass the pointers to these subclasses to
- the correct methods and the program runs as expected.
-
- If you changed PERSON.H to use a pure virtual function, it will
- still work with this program just as we discussed earlier.
-
-
- WHAT GOOD IS ALL OF THIS
- _________________________________________________________________
-
- Now that we have the program completely debugged and working,
- suppose that we wished to add another class to the program, for
- example a class named consultant because we wished to include some
- consultants in our business. We would have to write the class of
- course and the methods within the classes, but the linked list
- doesn't need to know that the new class is added, so it does not
- require any changes in order to update the program to handle
- consultant class objects. In this particular case, the linked list
- is very small and easy to understand, but suppose the code was very
- long and complex as with a large database. It would be very
- difficult to update every reference to the subclasses and add
- another subclass to every list where they were referred to, and
- this operation would be very error prone. In the present example
- program, the linked list would not even have to be recompiled in
- order to add the new functionality.
-
- It should be clear to you that it would be possible to actually
- define new types, dynamically allocate them, and begin using them
- even while the program was executing if we properly partitioned the
- code into executable units operating in parallel. This would not
- be easy, but it could be done for a large database that was
- tracking the inventory for a large retail store, or even for an
- airlines reservation system. You probably have little difficulty
- understanding the use of dynamically allocated memory for data, but
- dynamically allocating classes or types is new and difficult to
- grasp, but the possibility is there with dynamic binding.
-
-
- PROGRAMMING EXERCISES
- _________________________________________________________________
-
-
- 1. Add a new class named consultant to the files named SUPERVSR.H
- and SUPERVSR.CPP, then add code to EMPLOYE2.CPP to exercise
- the new class. Note that you do not need to recompile the
- linked list class in order to execute the new code and use the
- new class. Even without recompiling the linked list class it
- is capable of storing and passing the new class of data
- provided of course that the new class is referred to using a
- pointer to the parent class.
-
-
- Page 11-6
-